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Dear Sir: 



Applicants submit this Appeal Brief pursuant to the Notice of Appeal filed in this case on 
June 22, 2010, and the Notice of Panel Decision from Pre-Appeal Brief Review dated 
September 23, 2010. The fee for this Appeal Brief is being paid electronically via the USPTO EFS. 
The Board is authorized to deduct any other amounts required for this appeal brief and to credit any 
amounts overpaid to Deposit Account No. 502264. 

I. REAL PARTY IN INTEREST - 37 CFR § 41.37(c)(l)(i) 

The real party in interest is the assignee, GlobalFoundries Inc., as named in the caption 
above and as evidenced by the assignment set forth at Reel 023120, Frame 0426. 

II. RELATED APPEALS AND INTERFERENCES - 37 CFR $ 41.37(c)(l)(ii) 

Based on information and belief, there are no appeals or interferences that could directly 
affect or be directly affected by or have a bearing on the decision by the Board of Patent Appeals 
and Interferences in the pending appeal. However, Applicants would note that the present case was 
previously appealed in a Notice of Appeal dated August 28, 2008, and in another Notice of Appeal 
dated May 22, 2009. In both cases, prosecution was reopened. 

III. STATUS OF CLAIMS - 37 CFR § 41.37(c)(l)(iii) 

Claim 1 has been cancelled. Claims 2-6 are pending in the application. Claims 2-6 stand 
rejected. The rejection of claims 2-6 is appealed. Appendix "A" contains the full set of pending 
claims. 
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IV. STATUS OF AMENDMENTS - 37 CFR § 41.37(cXlXiv) 

On May 25, 2010, Applicants filed an Amendment and Response to Final Office Action 
proposing amendments to independent claims 2-5 to clarify that "a single flag" is used for each 
packet class, but the proposed amendments were not entered by the Advisory Action dated June 16, 
2010. 

V. SUMMARY OF CLAIMED SUBJECT MATTER - 37 CFR $ 41.37(cXl)(v) 

Applicants have invented a device verification method which provides a single dual-state 
flag for each of a plurality of packet classes . As recited, the single flag can have either a first state 
(e.g., "0" to indicate that the packet class has not been tested) or a second state (e.g., "1" to indicate 
that the packet class has been tested). It bears emphasis that the claims singularly and consistently 
recite "the flag" with reference to the earlier recitation of "a flag" which provides the antecedent 
basis for the recited single flag. When a packet from a packet class is generated, the single flag for 
that packet class is checked to see if it is in a first state, and if so, that packet is used to test the 
device for that packet class and the flag is changed to the second state. See, e.g., claim 2. On the 
other hand, if the single flag for that packet class is in a second state, the packet is not used to test 
the device for that packet class. See, e.g., claim 3. In this way, a device is tested by packet class 
since a packet within each packet class will only be used to test the device if the flag for that 
packet class has not been set to the second state. With Applicants' invention, packets need not be 
stored in memory, but can instead be "generated" as claimed (e.g., randomly), and each generated 
packet in a given packet class can be checked against the flag for that packet class to determine if 
the packet will be used to test the device. This approach eliminates the costs associated with storing 
all possible packets to be tested, and also eliminates the inefficient testing of devices with redundant 
packets by using a single flag for each packet class to determine if a generated packet in the packet 
class will be used to test the device. 

The subject matter defined in independent claim 2 (specification, page 2, line 1 to page 4, 
line 20 and page 7, lines 1-18) may be understood with reference to the example embodiment 
depicted in Figure 1 which depicts an exemplary flow diagram of a method for use in device 
verification. In the method, a plurality of packet classes are provided, and for each of the plurality 
of packet classes, a flag is provided which may be of a first or a second state. See, Figure 1 
("PROVIDE 1-BIT INJECTION FLAG . . . FOR EACH LEGAL PACKET CLASS"). 
Subsequently, a packet is generated. See, Figure 1 ("GENERATE PACKET"). If the flag of the 
packet class of the generated packet is in the first state, the device is tested and the flag of the packet 
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class of the generated packet is changed to the second state. See, Figure 1 ("RUN TEST" and "SET 
INJECTION FLAG OF THAT PACKET CLASS TO = 1"). Thus, the method for use in 
verification of a device recited in independent claim 2 (specification, page 2, lines 32-35, page 3, 
page 4, lines 1-12) includes providing a plurality of packet classes (10), providing a flag, which may 
be of a first or a second state, for each of the plurality of packet classes (10), and generating a 
packet (12); if the flag of the packet class of the generated packet is in the first state, testing the 
device (14, 16); if the flag of the packet class of the generated packet is in the first state, changing 
the flag of the packet class of the generated packet to the second state (14, 18). 

The subject matter defined in independent claim 2 (specification, page 2, line 1 to page 4, 
line 20 and page 7, lines 1-18) may be understood with reference to the example embodiment 
depicted in Figure 1 which depicts an exemplary flow diagram of a method for use in device 
verification. In the method, a plurality of packet classes are provided, and for each of the plurality 
of packet classes, a flag is provided which may be of a first or a second state. See, Figure 1 
("PROVIDE 1-BIT INJECTION FLAG ... FOR EACH LEGAL PACKET CLASS"). 
Subsequently, a packet is generated. See, Figure 1 ("GENERATE PACKET"). If the flag of the 
packet class of the generated packet is in the first state, the device is tested. See, Figure 1 ("RUN 
TEST" if injection flag of packet class does not equal 1). However, the flag of the packet class of 
the generated packet is in the second state, the device is not tested. See, Figure 1 (Return to 
"GENERATE PACKET" without running test if injection flag of packet class equals 1). Thus, the 
method for use in verification of a device recited in independent claim 3 (specification, page 2, lines 
32-35, page 3, page 4, lines 1-12) includes providing a plurality of packet classes (10), providing a 
flag, which may be of a first or a second state, for each of the plurality of packet classes (10), and 
generating a packet (12); if the flag of the packet class of the generated packet is in the first state, 
testing the device (14, 16); if the flag of the packet class of the generated packet is in the second 
state, not testing the device (14, 12). 

The subject matter defined in independent claim 4 (specification, page 2, line 1 to page 4, 
line 20 and page 7, lines 1-18) may be understood with reference to the example embodiment 
depicted in Figure 1 which depicts an exemplary flow diagram of a method for use in device 
verification. In the method, a plurality of packet classes are provided, and for each of the plurality 
of packet classes, a flag is provided which may be of a first or a second state. See, Figure 1 
("PROVIDE 1-BIT INJECTION FLAG . . . FOR EACH LEGAL PACKET CLASS"). 
Subsequently, a packet is generated. See, Figure 1 ("GENERATE PACKET"). If the flag of the 
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packet class of the generated packet is in the second state, the device is not tested. See, Figure 1 
(Return to "GENERATE PACKET" without running test if injection flag of packet class equals 1). 
Thus, the method for use in verification of a device recited in independent claim 4 (specification, 
page 2, lines 32-35, page 3, page 4, lines 1-12) includes providing a plurality of packet classes (10), 
providing a flag, which may be of a first or a second state, for each of the plurality of packet classes 
(10), and generating a packet'( 12); if the flag of the packet class of the generated packet is in the 
second state, not testing the device (14, 12). 

The subject matter defined in independent claim 5 (specification, page 2, line 1 to page 4, 
line 20 and page 7, lines 1-18) may be understood with reference to the example embodiment 
depicted in Figure 1 which depicts an exemplary flow diagram of a method for use in device 
verification. In the method, a plurality of packet classes are provided, and for each of the plurality 
of packet classes, an injection flag is provided which may be of a first or a second state. See, Figure 
1 ("PROVIDE 1-BIT INJECTION FLAG ... FOR EACH LEGAL PACKET CLASS"). 
Subsequently, a packet is generated. See, Figure 1 ("GENERATE PACKET"). If the injection flag 
of the packet class of the generated packet is in the second state, the device is not tested. See, 
Figure 1 (Return to "GENERATE PACKET" without running test if injection flag of packet class 
equals 1). However, if the injection flag of the packet class of the generated packet is in the first 
state, the device is tested. See, Figure 1 ("RUN TEST" if injection flag of packet class does not 
equal 1). Thus, the method for use in verification of a device recited in independent claim 5 
(specification, page 2, lines 32-35, page 3, page 4, lines 1-12) includes (a) providing a plurality of 
packet classes (10), (b) providing an injection flag, which may be of a first or a second state, for 
each of the plurality of packet classes (10), and (c) generating a packet (12); (d) if the injection flag 
of the packet class of the generated packet is in the second state, not testing the device (14, 12); (e) 
if the injection flag of the packet class of the generated packet is in the first state, testing the device 
and setting the injection flag of the packet class of the generated packet to the second state (14, 16, 
18). 

As seen from the foregoing, the subject matter of the independent claims is set forth in the 
Application at Figure 1 and the related discussion in the specification at page 2, line 1 to page 4, 
line 20 and page 7, lines 1-18, though additional contextual description is provided in the 
application and claims section. While Applicants have identified passages from the specification to 
explain the independent claim subject matter, it will be appreciated that the referenced description 
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includes contextual information to provide an overall context for an example embodiments, and 
therefore should not be used to improperly read limitations from the specification into the claims. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 2-6 were finally rejected as obvious over U.S. Patent Publication No. 2003/0172177 
to Kersley et al. in view of U.S. Patent Publication No. 2002/0190356 to Buechler et al. as 
evidenced by English, ADA 95: The Craft of Object-Oriented Programming. In this appeal, 
Applicants appeal the obviousness rejection of claims 2-6 over Kersley, Buechler, and English. 

VII. ARGUMENTS 

For the reasons set forth more fully below, Applicant respectfully requests that the rejection 
be reversed and that the claims be allowed because the Examiner has mischaracterized and 
overstated the claims in ignoring the clear and plain requirement that a single, two-state flag is used 
for each packet class to determine if the packet class is used to test the device. Based on the 
mischaracterized and overstated claim scope, the Examiner incorrectly asserts that Buechler' s use 
of "record flags" to assure that all required assay tests arc performed meets the claim requirements 
for a two-state injection flag, when in fact Buechler actually discloses using two separate flags 
instead of a single, two-state. Correctly construed and applied, Applicant submits that none of the 
cited references, either taken singly or in combination, disclose or suggest Applicant's claimed 
device verification method. 

A. Claims 2-6 Are Not Obvious Over Kersley, Buechler, and English 
As explained above, Applicants have invented a device verification method which provides a 
single dual-state flag for each of a plurality of packet classes . See, e.g., claim 2 ("providing a flag , 
which may be of a first or a second state, for each of the plurality of packet classes ."). As recited, 
the single flag can have either a first state (e.g., "0" to indicate that the packet class has not been 
tested) or a second state (e.g., "1" to indicate that the packet class has been tested). It bears 
emphasis that the claims singularly and consistently recite "a flag" or "the flag" with reference to 
the earlier recitation of "a flag" which provides the antecedent basis for the recited single flag. 
When a packet from a packet class is generated, the single flag for that packet class is checked to 
see if it is in a first state, and if so, that packet is used to test the device for that packet class and the 
flag is changed to the second state. See, e.g., claim 2. On the other hand, if the single flag for that 
packet class is in a second state, the packet is not used to test the device for that packet class. See, 
e.g., claim 3. In this way, a device is tested by packet class since a packet within each packet 
class will only be used to test the device if the flag for that packet class has not been set to the 
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second state. With Applicants' invention, packets need not be stored in memory, but can instead be 
"generated" as claimed (e.g., randomly), and each generated packet in a given packet class can be 
checked against the flag for that packet class to determine if the packet will be used to test the 
device. This approach eliminates the costs associated with storing all possible packets to be tested, 
and also eliminates the inefficient testing of devices with redundant packets by using a single flag 
for each packet class to determine if a generated packet in the packet class will be used to test the 
device. 

In rejecting claims 2-6 as obvious over Kersley, Buechler and English, the Examiner asserts 
that Kersley's disclosed method for verification of a device-under-test (Kersley, Fig. 2, ]f]f 5-7, 18, 
21-22, 35, and 43) meets the claim requirements except for variously recited requirements of (1) 
"providing a flag, which may be of a first or a second state, for each of the plurality of packet 
classes" (claims 2-6); (2) testing the device "if the flag of the packet class of the generated packet is 
in the first state" (claims 2-3 and 5-6); (3) not testing the device "if the flag of the packet class of 
the generated packet is in the second state" (claims 3-6); and (4) "changing the flag of the packet 
class of the generated packet to the second state" if the flag of the packet class of the generated 
packet is in the first state (claims 2 and 5-6). See, Office Action , pp. 2-6. To overcome these 
deficiencies in Kersley's disclosure, the Examiner cites Buechler's disclosure (Buechler, \ 78) of 
using "record flags" to assure that all required assay tests are performed and to avoid duplication of 
testing. Id., pp. 6-8. In reply and as explained more fully below, Applicants respectfully submit 
that a prima facie case of obviousness has not been established because the Examiner has failed to 
establish any of the three basic criteria required to establish a prima facie case of obviousness. 
First, there must be some suggestion or motivation, either in the reference itself or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference as proposed by the 
Examiner. Second, there must be a reasonable expectation of success. Finally, the prior art 
reference must teach or suggest all the claim limitations. The teaching or suggestion to modify the 
reference and the reasonable expectation of success must both be found in the prior art, not in 
Applicants' disclosure. MPEP §§ 2143.01-03. 

The prima facie case fails because the cited art fails to teach or suggest all the claim 
limitations. See, MPEP §§ 2143.03 ("All words in a claim must be considered in judging the 
patentability of that claim against the prior art."). In particular, Applicants submit that there are 
numerous deficiencies in the rejection analysis. First of all, the Examiner's rejection analysis does 
not recognize that a single flag is used for each packet class to convey the test status of the packet 
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class, asserting that "the claims does (sic, do) not explicitly state 'a single flag', but merely 'a flag'. 

This claimed language does not exclude the possibility of having multiple flags for a packet class, 

but merely states that there is a flag for a packet class." See, Office Action , pp. 8-9 (emphasis in 

original). As a result, the Examiner (incorrectly) asserts that Buechler's two separate flags meet the 

claim limitation of "a flag." Id. 

In reply, Applicants respectfully submit that the Examiner's proposed interpretation and 

application of the claims is incorrect because it fails to take into account the clear and explicit claim 

requirements that there is "a flag" with two states, that the device is tested with a packet if "the 

flag" is in a first state, and that "the flag" is changed to the second state if "the flag" is in the first 

state. The singular nature of "the flag" recited in the claims follows directly from the claim 

formatting requirements for reciting an antecedent basis for the claimed "flag" limitation, and 

Applicants submit that persons having ordinary skill in the art would readily understand as much 

from the recited language. Applicants proposed reading of the claims is consistent, not only with 

the explicit requirements of "the flag" in claims, but also with the intrinsic evidence: 

In the present method for use in verification of a device, a plurality of injection flags are 
provided, with one each of which is associated of a plurality of packet classes . Each 
injection flag may be of a first or a second state. Next, a packet is generated. If the in jection 
flag of the packet class of the generated packet is in the second state, it is indicated that a 
packet of that packet class has already been generated, and the device is not tested. If the 
injection flag of the packet class of the generated packet is in the first state, the device is 
tested and the injection flag of the packet class of the generated packet is set to the second 
state. 

* * * 

Figure 1 illustrates the steps of the present invention. In the present simulation, initially, 
each legal packet class is provided with a 1-bit injection flag . 

See, Application, p. 2, lines 1-9 and 32-33. As these passages show, Applicants have disclosed and 

claimed using a single flag for each packet class to drive and determine these various actions (test, 

not test, change flag state). In contrast, the cited art explicitly discloses using a plurality of record 

flags to track tests and prevent duplication. See, Buechler, U 78 ("In order to assure that all required 

tests are performed, and also to avoid duplication of testing, record flags or other techniques can be 

used when the database 464 is accessed to retrieve test instructions. For example, when fluorometer 

100 accesses information system 408 to receive instructions for a particular test, that test is flagged 

as being performed such that subsequent accesses by this or another fluorometer 100 will not 

retrieve the same test instructions. Once a test is completed and the results provided to information 

system 408, another flag can be set indicating the status of the test as being completed.") (emphasis 
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added). Thus, Applicants' approach is more efficient than the cited art because Applicants use a 
single flag to convey test status information for each packet, while the cite art uses multiple record 
flags to track tests and prevent duplicate testing. 

In this case, the rejection analysis appears to have mischaracterized the claimed invention by 
ignoring the requirement that a single flag be used for each packet class to determine: 

(1) whether the device is tested with the generated packet (as variously required in claims 2- 
3 and 5-6 which require device testing "if the flag of the packet class of the generated packet 
is in the first state"); 

(2) whether the device is not tested with the generated packet (as variously required in 
claims 3-6 which require no device testing "if the flag of the packet class of the generated 
packet is in the second state"); and/or 

(3) whether the flag is changed to a second state (as variously required in claims 2 and 5-6 
which require changing the flag state if the flag of the packet class of the generated packet is 
in the first state"). 

See, e.g., claims 2-5. In short, Applicants have disclosed and claimed using a single flag for each 
packet class to drive and determine these various actions (test, not test, change flag state). 

Against this backdrop, Applicants urge reconsideration and withdrawal of the rejection over 
Kersley, Buechler and English because the proposed combination fails to disclose or address the 
variously recited requirements in claims 2-3 and 5-6 of testing the device "if the flag of the packet 
class of the generated packet is in the first state" since Buechler discloses accessing the test 
instructions without first checking the state of an associated flag for the test. Likewise, rather than 
meeting the variously recited requirements in claims 3-6 of not testing the device "if the flag of the 
packet class of the generated packet is in the second state," Buechler discloses accessing "another 
flag" (not the same flag) to see if the test has been completed. Finally, rather than meeting the 
variously recited requirements in claims 2 and 5-6 of changing the flag to the second state "if the 
flag of the packet class of the generated packet is in the first state," Buechler discloses setting 
"another flag can be set" (not the same flag) "[o]nce a test is completed and the results provided to 
information system 408." In sum, Buechler uses two flags, not one flag as claimed, and sets the 
flags in response to different triggers than claimed. Buechler' s use of multiple flags for each test 
should come as no surprise since Buechler 's fluorometer testing scheme is concerned with only a 
limited number of tests, so there would be no significant penalty in tracking multiple flags for each 
test. In contrast, Applicants' disclosed verification scheme is being used to test devices with 
"several thousand different combinations" of possible packet classes being tested. See, Application , 
p. 1, lines 20-21. 

8 



Another problem with the cited art is that neither Kersley nor Buechler disclose or suggest 
"providing a plurality of packet classes ," much less "providing a flag ... for each of the plurality of 
packet classes " as recited in each of the pending claims. On this point, Applicants have carefully 
review the cited disclosure from Kersley (Fig. 2, ]H| 5-7, 18, 21-22, 35, 43), but there is absolutely 
no teaching or suggestion of any "packet class," much less of providing a single flag for each 
"packet class." And while Buechler discloses maintaining a flag for each assay test performed by 
the fluorometer, there is no suggestion of maintaining a flag for a class of tests. Thus, there is 
simply no teaching or suggestion that the cited art combination provides "a plurality of packet 
classes" with a (single) flag "for each of the plurality of packet classes," as recited in the claims. 
Instead of being concerned with testing by packet class, Kersley is concerned with verifying a 
device-under-test by "generating packets to simulate complex network packet traffic patterns to test 
and verify a device under test (DUT)." Kersley, paragraph 5. 

In addition to the missing claim requirements detailed above, the prima facie case fails 
because the Examiner has provided zero evidence of any suggestion or motivation to combine the 
Kersley, Buechler and English references. See, MPEP § 2143.01 ("Suggestion or Motivation to 
Modify the References" is required.). This deficiency is seen from the Examiner's rejection 
analysis of claim 2 where the Examiner admits that Kersley fails to disclose the claim requirements 
for providing a two-state flag for each of the plurality of test types and changing the flag to the 
second state if the flag is in the first state, but then proceeds to assert, without support, that it would 
have been obvious to combine Buechler's description of using "records flags. . . 
test. . .flagged. . .flag. . .test as being completed." See, Office Action , pp. 5-6. The proffered 
motivation-to-combine evidence consists of the unsupported assertion that: 

It would have been obvious to one of the (sic) ordinary skill in the art at the time of the 
invention to modify / combine the features of Kersley by using the above recited features, as 
taught by Beuchler, or order to provide a method a (sic) preventing duplicate testing, thus 
decreasing wasteful testing time and additional resources used by not performing tests that 
already have been performed (see Beuchler sections 0078). One could have implemented 
the teaching of Beuchler to the concept of test packets of Kersley, where flags are kept for 
the different packet types / combination. 

See, Office Action , p. 8. To the extent that the purported objective of "preventing duplicate testing" 
could be achieved by Beuchler' s plurality of record flags for each, the proffered motivation-to- 
combine evidence is wholly devoid of any explanation of how a person skilled in the art would be 
motivated by Beuchler's disclosure to meet the requirements recited in the claims for using a single, 
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two-state to keep track of which packets have been tested on the device. See, DyStar Textilfarben 
GMBH y.C.H. Patrick Co. . 464 F.3d 1356, 80 USPQ2d 1641 (Fed. Cir. 2006) ("'[C]onclusory 
statements such as those here provided do not fulfill the agency's obligation' to explain all material 
facts relating to a motivation to combine. . . . We instructed that assumptions about common sense 
cannot substitute for evidence thereof. . ."). This wholly unsupported assertion does not meet the 
requirement of a prima facie showing of obviousness announced in the recent KSR decision 
whereby the Examiner must provide "some articulated reasoning with some rationale underpinning 
to support the legal conclusion of obviousness" and must "identify a reason that would have 
prompted a person of ordinary skill in the relevant field to combine the elements in the way the 
claimed new invention does." KSR v. Teleflex , 127 S. Ct. 1727, 82 U.S.P.Q.2d 1385 (2007). In 
addition, the Examiner must make "explicit" this rationale of "the apparent reason to combine the 
known elements in the fashion claimed," including a detailed explanation of "the effects of demands 
known to the design community or present in the marketplace" and "the background knowledge 
possessed by a person having ordinary skill in the art." Id. Anything less than such an explicit 
analysis does not meet the requirement of a prima facie case of obviousness. Indeed, the attempted 
reliance on Buechler to remedy Kersley's admitted deficiencies actually teaches away from 
Applicant's claimed invention since Belcher explicitly discloses using a plurality of record flags for 
each assay test to track tests and prevent duplication. See, Buechler, U 78 ("In order to assure that 
all required tests are performed, and also to avoid duplication of testing, record flags or other 
techniques can be used when the database 464 is accessed to retrieve test instructions. For example, 
when fluorometer 100 accesses information system 408 to receive instructions for a particular test, 
that test is flagged as being performed such that subsequent accesses by this or another fluorometer 
100 will not retrieve the same test instructions. Once a test is completed and the results provided to 
information system 408, another flag can be set indicating the status of the test as being 
completed.") (emphasis added). See, MPEP § 2144.05(111) ("A prima facie case of obviousness 
may also be rebutted by showing that the art, in any material respect, teaches away from the claimed 
invention. In re Geisler , 116 F.3d 1465, 1471, 43 USPQ2d 1362, 1366 (Fed. Cir. 1997)"). KSR 
International Co. v. Teleflex Inc. . 82 USPQ2d 1385, 1395 (2007) ("When the prior art teaches away 
from combining certain known elements, discovery of successful means of combining them is more 
likely to be nonobvious."). Where there is no suggestion to combine the teachings and suggestions 
of Kersley and Beuchler as advanced by the Examiner, this appears to be an improper use of 
Applicants' invention as a template through hindsight reconstruction of Applicants' claims. See, Ex 
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Parte Crawford et aL , Appeal No. 20062429 (BPAI 2007) and Ex Parte Erkev et al. Appeal 
20071375 (BPAI May 11, 2007) (reversing rejection of claim as obvious where Examiner failed to 
provide sufficient evidence and explicit analysis of why the disclosures of the references should be 
combined.). 

Finally, the prima facie case fails because the Examiner has failed to articulate a finding that 
there was a reasonable expectation of success. See, MPEP §§ 2143.02 ("Reasonable Expectation of 
Success Is Required"). The rejection analysis set forth in the Office Action is entirely silent on the 
question of whether there is a reasonable expectation of success, as there is rationale provided to 
support the assertion that the claimed invention would have been obvious. See, Office Action , pp. 
2-11. 

Based on the foregoing, Applicants submit that a prima facie case of obviousness has not 
been established for claims 2-6 because the Examiner has not met the burden of showing that all the 
claim limitations are taught or suggested by the prior art. In the absence of any disclosure by the 
cited art references of a device verification method which provides a single flag for each of a 
plurality of packet classes for purposes of performing device verification testing on each packet, the 
Examiner has not made the prima facie showing that each and every element of the claimed 
invention, arranged as required by the claims, is found in the cited art. When determining whether a 
claim is obvious, an Examiner must make "a searching comparison of the claimed invention - 
including all its limitations - with the teaching of the prior art." In re Ochiai , 71 F.3d 1565, 1572 
(Fed. Cir. 1995) (emphasis added). Thus, "obviousness requires a suggestion of all limitations in a 
claim." CFMT, Inc. v. Yieldup Intern. Corp. , 349 F.3d 1333, 1342 (Fed. Cir. 2003) (citins In re 
Royka, 490 F.2d 981, 985 (CCPA 1974)). Moreover, the Supreme Court has made clear that "there 
must be some articulated reasoning with some rational underpinning to support the legal conclusion 
of obviousness." KSR Int'l v. Teleflex Inc. , 127 S.Ct. 1727, 1741 (2007) {quoting In re Kahn , 441 
F.3d 977, 988 (Fed. Cir. 2006) (emphasis added)). Accordingly, Applicants respectfully request 
that the obviousness rejection of claims 2-6 be reconsidered and withdrawn, and that the claims be 
allowed. 

VIII. CLAIMS APPENDIX - 37 CFR § 41.37(cKlXviii) 

A copy of the pending claims involved in the appeal is attached as Appendix "A." 

IX. EVIDENCE APPENDIX - 37 CFR § 41.37(c)(lXix) 

None. 
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X. RELATED PROCEEDINGS APPENDIX - 37 CFR $ 41.37(cXlXx) 

There are no related proceedings. 

XI. CONCLUSION 

In view of the above arguments, it is respectfully urged that the rejection of the claims 
should not be sustained. 
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APPENDIX A - PENDING CLAIMS 



1 . (Canceled) 

2. (Previously Presented) A method for use in verification of a device 
comprising: 

providing a plurality of packet classes; 

providing a flag, which may be of a first or a second state, for each of the plurality of packet 

classes; 
generating a packet; 

if the flag of the packet class of the generated packet is in the first state, testing the device; 
if the flag of the packet class of the generated packet is in the first state, changing the flag of 
the packet class of the generated packet to the second state. 

3. (Previously Presented) A method for use in verification of a device 
comprising: 

providing a plurality of packet classes; 

providing a flag, which may be of a first or a second state, for each of the plurality of packet 

classes; 
generating a packet; 

if the flag of the packet class of the generated packet is in the first state, testing the device; 
if the flag of the packet class of the generated packet is in the second state, not testing the 
device. 

4. (Original) A method for use in verification of a device comprising: 
providing a plurality of packet classes; 

providing a flag, which may be of a first or a second state, for each of the plurality of packet 

classes; 
generating a packet; 

if the flag of the packet class of the generated packet is in the second state, not testing the 
device. 
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5. (Original) A method for use in verification of a device comprising: (a) providing 
a plurality of packet classes; 

(b) providing an injection flag, which may be of a first or a second state, for each of the 

plurality of packet classes; 

(c) generating a packet; 

(d) if the injection flag of the packet class of the generated packet is in the second state, not 

testing the device; 

(e) if the injection flag of the packet class of the generated packet is in the first state, testing 

the device and setting the injection flag of the packet class of the generated packet to 
the second state. 

6. (Original) The method of claim 5 and further comprising repeating steps (c) 
through (e) thereof 
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EVIDENCE APPENDIX - 37 CFR § 41.37(c)(l)(ix) 

None. 
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RELATED PROCEEDINGS APPENDIX - 37 CFR § 41.37(cXlXx) 

There are no related proceedings. 
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